개요

이번에는 조금 더 심화된 내용으로, 트래픽을 미러링하는 방법을 알아본다.
이 내용만 다루지만, 대신 조금 자세하게 패킷을 캡쳐해서 어떤 식으로 미러링 기능이 동작하는지 볼 것이다.

사전 지식

트래픽 미러링이란

트래픽 미러링은 라우팅될 트래픽을 그대로 복사하여 다른 곳으로도 보내는 기법을 말한다.
복사된 트래픽을 받은 입장에서는 일반적으로 트래픽이 온 것으로 간주하고 응답을 보내지만, 트래픽을 보낸 엔보이는 해당 응답을 무시한다.
새로운 배포 버전을 릴리스할 때 이 방식을 사용하면 실제 사용자의 트래픽을 이용해서 테스트를 하면서도 사용자의 요청은 안정적인 버전으로 그대로 유지시킬 수 있다는 장점이 있다.

실습 진행

미러링 세팅

kubectl apply -f services/catalog/kubernetes/catalog-svc.yaml -n istioinaction
kubectl apply -f services/catalog/kubernetes/catalog-deployment.yaml -n istioinaction
kubectl apply -f services/catalog/kubernetes/catalog-deployment-v2.yaml -n istioinaction
kubectl apply -f ch5/catalog-dest-rule.yaml -n istioinaction
kubectl apply -f ch5/catalog-vs-v1-mesh.yaml -n istioinaction

다시 환경을 세팅한다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: catalog
spec:
  hosts:
  - catalog
  gateways:
    - mesh
  http:
  - route:
    - destination:
        host: catalog
        subset: version-v1
      weight: 100
    mirror:
      host: catalog
      subset: version-v2

mirror 필드를 세팅하면 간단하게 트래픽을 미러링할 수 있게 된다.

webapp 엔보이의 라우팅 설정을 보면 requestMirrorPolicies 가 생긴 것을 볼 수 있다.

키알리 상으로도 각 버전에 트래픽을 똑같이 보내는 것이 확인된다.

이때 시각화에서 버튼에서 리퀘스트의 throughput을 보면 v2에는 데이터가 집계되지 않는 것을 확인할 수 있다.

kubectl logs -n istioinaction -l app=catalog -l version=v2 -c catalog -f

미러 트래픽을 받는 어플리케이션의 로그를 보면 호스트에 -shadow라는 값이 붙는 것을 볼 수 있다.
미러 트래픽을 받는 쪽에 이 정도의 단서를 제공해주긴 하기 때문에 실제 운영 시에는 이걸 활용해 받는 쪽에서 어떻게 처리할지 조금 더 세부적으로 지정할 수 있다.

그나저나 내가 뭘 또 잘못한 것인지, 미러링되고 있다는 아이콘이 표시되지는 않았다.

미러링 패킷 확인

노드 단에서 확인

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: DISABLE

조금 더 확실하게 보기 위해서 아예 패킷 덤프를 떠보자.
일단 데이터 상태 확인을 위해 mtls를 비활성화한다.

docker exec myk8s-control-plane tcpdump -i any -c 1000 -w /istiobook/capture.pcap 

컨트롤 플레인만 있으므로 패킷을 확인하는 작업이 상대적으로 쉽다.
패킷을 그대로 떠서 호스트로 마운팅 되고 있는 경로에 저장해서 구경해보면..

http 트래픽만 걸러서 보면 미러링되고 있는 트래픽 정보를 금새 확인할 수 있다.

참고로 각 파드의 ip도 정확하게 일치한다.
미러링된 요청의 응답을 무시한다는 것이 아예 tcp 연결을 끊어버리는 건가 했는데, 그건 아니고 분명히 응답을 받긴 하고 그걸 사용하지 않는다는 의미로 이해하면 되겠다.
다시 말해 미러링을 한 엔보이는 미러 응답을 자신의 어플리케이션에 돌려보내지 않는다는 말이다.

k run debug --image nicolaka/netshoot -ti -- zsh
curl catalog/items

아예 디버깅 파드를 띄워서 패킷도 캡쳐해봤다.

내부 패킷 상으로도 정상적으로 미러 응답이 들어온다.

컨테이너 내부에서 확인

이렇게만 보려니 뭔가 아쉽다.
아예 컨테이너 내부에서 일어나는 패킷을 뜯어서 보자.

apiVersion: v1
kind: Pod
metadata:
  name: debug
spec:
  volumes:
    - name: local
      hostPath:
        path: "/istiobook"
  containers:
    - name: debug
      image: nicolaka/netshoot
      command: [sh, -c, "sleep 60d"]
      volumeMounts:
        - mountPath: /istiobook
          name: local
  terminationGracePeriodSeconds: 0

디버깅 파드에 호스트패스 볼륨을 두어 패킷 덤프 파일을 꺼내 볼 수 있게 만들었다.

keti debug -- tcpdump -i any -c 40 -w /istiobook/localhost.pcap
keti debug -- curl catalog/items

이 상태에서 두어번 요청을 보낸다.
해보니까 패킷을 20개 정도만 캡쳐해도 됐을 것이다.

이제 조금 더 패킷을 자세히 볼 수 있게 됐다!
iptables로 패킷 장난질이 마구 이뤄지다보니 제대로 보기는 힘든데(좀 더 좋게 보는 방법 아시는 분..), 대충 정리하자면 이렇다.

• curl 프로세스(48612)에서 요청 발생
  • 이 요청은 사실 localhost로 15001포트를 열고 있는 엔보이에게 들어간다.
    • 이건 파드 초기화 시 pilot-agent가 iptables로 장난질 쳐서 그렇다.
  • tcp 연결이 먼저 이뤄지는데, 엔보이는 curl 프로세스 입장에서 catalog의 80번 포트에서 연결을 수락한 것마냥 잘 포장해서 보여준다.
  • http 요청이 날아간다.
• envoy가 파드 외부로 요청을 보낸다.
  • 먼저 v1의 catalog에 요청(48756)
  • 그리고 v2의 catalog에 요청(50600)
  • 두 응답 모두 정상적으로 돌아온다.
• curl 프로세스 응답 반환
  • envoy가 외부에서 응답이 온 것마냥 잘 포장해서 curl 프로세스(48612)로 트래픽을 돌려보낸다.

보다시피 미러링은 이뤄졌으나 실제 프로세스에게 돌려주는 응답은 v1, 즉 이미지 url 정보가 없는 응답 하나 뿐이란 것을 알 수 있다.

결론

미러링 기능을 처음 알게 됐을 때 응답을 버린다고 하길래 나는 아예 iptables에서 드랍을 시켜버리는 게 아닐까 생각했었는데, 조금 더 구체적으로 패킷을 뜯어보고 나서 어떤 식으로 동작하는지 알 수 있었다.
엔보이는 미러링을 해서 트래픽을 전달하고 응답까지 받으나, 그걸 원래 다운스트림으로 돌려주지 않을 뿐이다.

이 미러링과 비슷한 기능으로, 리퀘스트 헤징이라는 것이 있는데, 이것도 다음 글 정도에서 보게 될 것이다.

이전 글, 다음 글

• 3W - 트래픽 가중치 - flagger와 argo rollout을 이용한 점진적 배포: 8
• 3W - 서비스 엔트리와 이그레스 게이트웨이: 10

다른 글 보기

관련 문서

참고